home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HAM Radio 3.2
/
Ham Radio Version 3.2 (Chestnut CD-ROMs)(1993).ISO
/
exam
/
g1emmnos
/
userref.out
< prev
next >
Wrap
Text File
|
1990-09-26
|
128KB
|
2,641 lines
NNNEEETTT UUUssseeerrr RRReeefffeeerrreeennnccceee MMMaaannnuuuaaalll (((NNNOOOSSS VVVeeerrrsssiiiooonnn)))
Phil Karn, KA9Q
111... TTThhheee NNNEEETTT...EEEXXXEEE PPPrrrooogggrrraaammm
The MS-DOS executable file nnneeettt...eeexxxeee provides Internet (TCP/IP), NET/ROM and
AX.25 facilities. Because it has an internal multitasking operating system,
nnneeettt...eeexxxeee can act simultaneously as a client, a server and a packet switch for
all three sets of protocols. That is, while a local user accesses remote
services, the system can also provide those same services to remote users
while also switching IP, NET/ROM and AX.25 packets and frames between other
client and server nodes.
The keyboard and display is used by the local operator to control both host
and gateway level functions, for which a number of commands are provided.
111...111... SSStttaaarrrtttuuuppp
When nnneeettt...eeexxxeee is executed without arguments, it attempts to open the file
aaauuutttoooeeexxxeeeccc...nnneeettt in the root directory of the current drive. If it exists, it is
read and executed as though its contents were typed on the console as
commands. This feature is useful for attaching communication interfaces,
configuring network addresses, and starting the various services. If nnneeettt...eeexxxeee
is invoked with an argument, it is taken to be the name of an alternate
startup file to be read instead of aaauuutttoooeeexxxeeeccc...nnneeettt.
Three command-line options are accepted:
111...111...111... ---bbb
The ---bbb option specifies the use of BIOS for console output; the default is to
write directly to the video display buffer. Use this option if you are running
under a windowing package and have trouble with output "bleeding through" on
top of other windows.
111...111...222... ---sss
The ---sss option specifies the size of the _s_o_c_k_e_t array to be allocated within
net. This limits the number of network connections that may exist
simultaneously; the default is 40.
- 2 -
111...111...333... ---ddd
The ---ddd option allows the user to specify a "root" directory for the
configuration and spool files; it defaults to the root directory of the
system.
222... CCCooonnnsssooollleee mmmooodddeeesss
The console may be in one of two modes: _c_o_m_m_a_n_d _m_o_d_e and _c_o_n_v_e_r_s_e _m_o_d_e. In
command mode, the prompt nnneeettt>>> is displayed and any of the commands described
in the next section may be entered. In converse mode, keyboard input is
processed according to the _c_u_r_r_e_n_t _s_e_s_s_i_o_n. Sessions come in eight types:
_T_e_l_n_e_t, _F_T_P, _A_X_2_5, _N_E_T_R_O_M, _P_i_n_g, _M_o_r_e, _H_o_p_c_h_e_c_k and _T_i_p.
In a Telnet, AX25, NETROM, or Tip session, keyboard input is sent to the
remote system and any output from the remote system is displayed on the
console. In an FTP session, keyboard input is first examined to see if it is
a known local command; if so it is executed locally. If not, it is "passed
through" to the remote FTP server. (See the section titled FFFTTTPPP SSSuuubbbcccooommmmmmaaannndddsss).
In a Ping session the user may test the path to a remote site, and in a More
session, the user may examine a local file. A Hopcheck session is used to
trace the path taken by packets to reach a specified destination.
The keyboard also has _c_o_o_k_e_d and _r_a_w states. In cooked state, input is line-
at-a-time; the user may use the line editing characters ^U, ^R and backspace
to erase the line, redisplay the line and erase the last character,
respectively. Hitting either return or line feed passes the complete line up
to the application. In raw mode, each character is immediately passed to the
application as it is typed. The keyboard is always in cooked state in command
mode. It is also cooked in converse mode on an AX25, FTP or NET/ROM session.
In a Telnet session it depends on whether the remote end has issued (and the
local end has accepted) the Telnet WILL ECHO option. (See the eeeccchhhooo command).
On the IBM-PC, the user may escape back to command mode by hitting the F10
key. On other systems, the user must enter the _e_s_c_a_p_e character, which is by
default control-] (hex 1d, ASCII GS). (Note that this is distinct from the
ASCII character of the same name). The escape character can be changed (see
the eeessscccaaapppeee command).
In the IBM PC version, each session (including the command "session") has its
own screen. When a new session is created, the command display is saved in
memory and the screen is cleared. When the command escape key (usually F10) is
hit, the current session screen is saved and the command screen is restored.
When a session is resumed, its screen is restored exactly as it appeared when
it was last current.
333... CCCooommmmmmaaannndddsss
This section describes the commands recognized in command mode. These are
given in the following notation:
- 3 -
command
command literal_parameter
command subcommand <parameter>
command [<optional_parameter>]
command a|b
Many commands take subcommands or parameters, which may be optional or
required. In general, if a required subcommand or parameter is omitted, an
error message will summarize the available subcommands or required parameters.
(Giving a '?' in place of the subcommand will also generate the message. This
is useful when the command word alone is a valid command.) If a command takes
an optional value parameter, issuing the command without the parameter
generally displays the current value of the variable. (Exceptions to this rule
are noted in the individual command descriptions.)
Two or more parameters separated by vertical bar(s) denote a choice between
the specified values. Optional parameters are shown enclosed in [brackets],
and a parameter enclosed in <angle brackets> should be replaced with an actual
value or string. For example, the notation <<<hhhooossstttiiiddd>>> denotes an actual host or
gateway, which may be specified in one of two ways: as a symbolic name listed
in the file ///dddooommmaaaiiinnn...tttxxxttt, or as a numeric IP address in dotted decimal
notation, e.g., 44.0.0.1. If a domain name server is available on the network
and configured into _n_e_t, it will be queried if the name isn't found in
///dddooommmaaaiiinnn...tttxxxttt.
All commands and many subcommands may be abbreviated. You only need type
enough of a command's name to distinguish it from others that begin with the
same series of letters. Parameters, however, must be typed in full.
Certain FTP subcommands, e.g., pppuuuttt,,, gggeeettt,,, dddiiirrr, etc, are recognized only in
converse mode with the appropriate FTP session; they are not recognized in
command mode.
333...111... <<<cccrrr>>>
Entering a carriage return (empty line) while in command mode puts you in
converse mode with the current session. If there is no current session, _n_e_t
remains in command mode.
333...222... !!!
An alias for the ssshhheeellllll command.
333...333... ###
Commands starting with the hash mark (#) are ignored. This is mainly useful
for comments in the aaauuutttoooeeexxxeeeccc...nnneeettt file.
333...444... aaabbbooorrrttt [[[<<<ssseeessssssiiiooonnn ###>>>]]]
- 4 -
Abort a FTP gggeeettt,,, pppuuuttt ooorrr dddiiirrr operation in progress. If issued without an
argument, the current session is aborted. (This command works only on FTP
sessions.) When receiving a file, aaabbbooorrrttt simply resets the data connection; the
next incoming data packet will generate a TCP RST (reset) response to clear
the remote server. When sending a file, aaabbbooorrrttt sends a premature end-of-file.
Note that in both cases aaabbbooorrrttt will leave a partial copy of the file on the
destination machine, which must be removed manually if it is unwanted.
333...555... aaarrrppp
Display the Address Resolution Protocol table that maps IP addresses to their
subnet (link) addresses on subnetworks capable of broadcasting. For each IP
address entry the subnet type (e.g., Ethernet, AX.25), subnet address and time
to expiration is shown. If the link address is currently unknown, the number
of IP datagrams awaiting resolution is also shown.
333...666... aaarrrppp aaadddddd <<<hhhooossstttiiiddd>>> eeettthhheeerrrnnneeettt|||aaaxxx222555 <<<eeettthhheeerrrnnneeettt aaaddddddrrreeessssss>>>|||<<<aaaxxx222555___aaaddddddrrreeessssss>>>
Add a permanent entry to the table. It will not time out as will an
automatically-created entry, but must be removed with the aaaxxx222555 dddrrroooppp command.
333...777... aaarrrppp pppuuubbbllliiissshhh <<<hhhooossstttiiiddd>>> eeettthhheeerrrnnneeettt|||aaaxxx222555 <<<eeettthhheeerrrnnneeettt aaaddddddrrreeessssss>>>|||<<<aaaxxx222555___aaaddddddrrreeessssss>>>
The aaarrrppp pppuuubbbllliiissshhh command is similar to the aaarrrppp aaadddddd command, but system will
also respond to any ARP request it sees on the network that seeks the
specified address. (Use this feature with great care.)
333...888... aaarrrppp dddrrroooppp <<<hhhooossstttiiiddd>>> aaaxxx222555|||eeettthhheeerrrnnneeettt
Remove the specified entry from the ARP table.
333...999... aaarrrppp fffllluuussshhh
Drop all automatically-created entries in the ARP table; permanent entries are
not affected.
333...111000... aaasssyyyssstttaaattt
Display statistics on attached asynchronous communications interfaces (8250 or
16550A), if any. The display for each port consists of three lines. The first
line gives the port label and the configuration flags; these indicate whether
the port is a 16550A chip, the _t_r_i_g_g_e_r _c_h_a_r_a_c_t_e_r if any, and whether CTS flow
control is enabled. (The trigger character when received causes the driver to
signal upper layer software that data is ready; it is automatically set to the
appropriate frame end character for SLIP and NRS lines.)
The second line of the status display shows receiver (RX) event counts: the
total number of receive interrupts, received characters, receiver overruns
(lost characters) and the receiver _h_i_g_h _w_a_t_e_r _m_a_r_k. The high water mark is
the maximum number of characters ever read from the device during a single
- 5 -
interrupt. This is useful for monitoring system interrupt latency margins as
it shows how close the port hardware has come to overflowing due to the
inability of the CPU to respond to a receiver interrupt in time. 8250 chips
have no FIFO, so the high water mark cannot go higher than 2 before overruns
occur. The 16550A chip, however, has a 16-byte receive FIFO which the software
programs to interrupt the CPU when the FIFO is one-quarter full. The high
water mark should typically be 4 or 5 when a 16550A is used; higher values
indicate that the CPU has at least once been slow to respond to a receiver
interrupt.
When the 16550A is used, a count of FIFO timeouts is also displayed on the RX
status line. These are generated automatically by the 16550A when three
character intervals go by with more than 0 but less than 4 characters in the
FIFO. Since the characters that make up a SLIP or NRS frame are normally sent
at full line speed, this count will usually be a lower bound on the number of
frames received on the port, as only the last fragment of a frame generally
results in a timeout (and then only when the frame is not a multiple of 4
bytes long.)
The third line shows transmit (TX) statistics, including a total count of
transmit interrupts, transmitted characters, the length of the transmit queue
in bytes, and the number of CTS interrupts (this latter value will be zero
unless CTS flow control has been enabled.)
333...111111... aaattttttaaaccchhh <<<hhhwww tttyyypppeee>>> .........
Configure and attach a hardware interface to the system. The details are
highly interface dependent. Drivers are available for the following hardware
types:
333...111111...111... aaasssyyy
Standard PC asynchronous interface (com port) using the National 8250 or
16550A chip.
333...111111...222... dddrrrsssiii
N6TTO driver for the DRSI PCPA 8530 card.
333...111111...333... eeeaaagggllleee
WA3CVG/NG6Q driver for the Eagle Computer card (Zilog 8530).
333...111111...444... hhhaaapppnnn
KE3Z driver for the Hamilton Amateur Packet Network adapter board (Intel
8273).
- 6 -
333...111111...555... hhhsss
Special "high speed" 8530 driver for the WA4DSY 56kb/s modem.
333...111111...666... pppaaaccckkkeeettt
Driver for use with separate software "packet drivers" meeting the FTP
Software, Inc, Software Packet Driver specification.
333...111111...777... pppccc111000000
Driver for the PACCOMM PC-100 (Zilog 8530) card.
333...111111...888... ssscccccc
PE1CHL driver for generic 8530 cards.
Detailed instructions for each driver are in the section AAAttttttaaaccchhh CCCooommmmmmaaannndddsss. An
easy way to obtain a summary of the parameters required for a given device is
to issue a partial attach command, e.g., aaattttttaaaccchhh pppaaaccckkkeeettt. This produces a usage
message giving the complete command format.
333...111222... aaaxxx222555 bbbllliiimmmiiittt [[[<<<vvvaaalll>>>]]]
Display or set the AX25 retransmission backoff limit. Normally each successive
AX25 retransmission is delayed by twice the value of the previous interval;
this is called _b_i_n_a_r_y _e_x_p_o_n_e_n_t_i_a_l _b_a_c_k_o_f_f. When the backoff reaches the
blimit setting it is held at that value, which defaults to 30. To prevent the
possibility of "congestion collapse" on a loaded channel, blimit should be set
at least as high as the number of stations sharing the channel.
333...111333... aaaxxx222555 dddiiigggiiipppeeeaaattt [[[ooonnn|||oooffffff]]]
Display or set the digipeater enable flag.
333...111444... aaaxxx222555 fffllluuussshhh
Clear the AX.25 "heard" list (see aaaxxx222555 hhheeeaaarrrddd).
333...111555... aaaxxx222555 hhheeeaaarrrddd
Display the AX.25 "heard" list. For each interface that is configured to use
AX.25, a list of all callsigns heard through that interface is shown, along
with a count of the number of packets heard from each station and the
interval, in hr:min:sec format, since each station was last heard. The local
station always appears first in the listing; the packet count actually
reflects the number of packets transmitted. This entry is always present even
if no packets have been sent.
- 7 -
333...111666... aaaxxx222555 iiirrrtttttt [[[<<<vvvaaalll>>>]]]
Display or set the initial value of smoothed round trip time to be used when a
new AX25 connection is created. The value is in milliseconds. The actual
round trip time will be learned by measurement once the connection has been
established.
333...111777... aaaxxx222555 kkkiiiccckkk <<<aaaxxxcccbbb>>>
Force a retransmission on the specified AX.25 control block.
333...111888... aaaxxx222555 mmmaaaxxxfffrrraaammmeee [[[<<<vvvaaalll>>>]]]
Establish the maximum number of frames that will be allowed to remain
unacknowledged at one time on new AX.25 connections. This number cannot be
greater than 7.
333...111999... aaaxxx222555 mmmyyycccaaallllll [[[<<<cccaaallllll>>>]]]
Display or set the local AX.25 address. The standard format is used, e.g.,
KA9Q-0 or WB6RQN-5. This command must be given before any attach commands
using AX.25 mode are given.
333...222000... aaaxxx222555 pppaaacccllleeennn [[[<<<vvvaaalll>>>]]]
Limit the size of I-fields on new AX.25 connections. If IP datagrams or
fragments larger than this are transmitted, they will be transparently
fragmented at the AX.25 level, sent as a series of I frames, and reassembled
back into a complete IP datagram or fragment at the other end of the link. To
have any effect on IP datagrams, this parameter should be less than or equal
to the MTU of the associated interface.
333...222111... aaaxxx222555 pppttthhhrrreeessshhh [[[<<<vvvaaalll>>>]]]
Display or set the poll threshold to be used for new AX.25 Version 2
connections. The poll threshold controls retransmission behavior as follows.
If the oldest unacknowledged I-frame size is less than the poll threshold, it
will be sent with the poll (P) bit set if a timeout occurs. If the oldest
unacked I-frame size is equal to or greater than the threshold, then a RR or
RNR frame, as appropriate, with the poll bit set will be sent if a timeout
occurs.
The idea behind the poll threshold is that the extra time needed to send a
"small" I-frame instead of a supervisory frame when polling after a timeout is
small, and since there's a good chance the I-frame will have to be sent anyway
(i.e., if it were lost previously) then you might as well send it as the poll.
But if the I-frame is large, send a supervisory (RR/RNR) poll instead to
determine first if retransmitting the oldest unacknowledged I-frame is
necessary; the timeout might have been caused by a lost acknowledgement. This
is obviously a tradeoff, so experiment with the poll threshold setting. The
default is 128 bytes, one half the default value of pppaaacccllleeennn.
- 8 -
333...222222... aaaxxx222555 rrreeessseeettt <<<aaaxxxcccbbb>>>
Delete the AX.25 connection control block at the specified address.
333...222333... aaaxxx222555 rrreeetttrrryyy [[[<<<vvvaaalll>>>]]]
Limit the number of successive unsuccessful retransmission attempts on new
AX.25 connections. If this limit is exceeded, link re-establishment is
attempted. If this fails rrreeetttrrryyy times, then the connection is abandoned and all
queued data is deleted.
333...222444... aaaxxx222555 rrrooouuuttteee
Display the AX.25 routing table that specifies the digipeaters to be used in
reaching a given station.
333...222555... aaaxxx222555 rrrooouuuttteee aaadddddd <<<tttaaarrrgggeeettt>>> [[[dddiiigggiiisss ......... ]]]
Add an entry to the AX.25 routing table. An automatic aaaxxx222555 rrrooouuuttteee aaadddddd is
executed if digipeaters are specified in an AX25 cccooonnnnnneeecccttt command, or if a
connection is received from a remote station via digipeaters. Such automatic
routing table entries won't override locally created entries, however.
333...222666... aaaxxx222555 rrrooouuuttteee dddrrroooppp <<<tttaaarrrgggeeettt>>>
Drop an entry from the AX.25 routing table.
333...222777... aaaxxx222555 ssstttaaatttuuusss [[[<<<aaaxxxcccbbb>>>]]]
Without an argument, display a one-line summary of each AX.25 control block.
If the address of a particular control block is specified, the contents of
that control block are dumped in more detail. Note that the send queue units
are frames, while the receive queue units are bytes.
333...222888... aaaxxx222555 ttt333 [[[<<<vvvaaalll>>>]]]
Display or set the AX.25 idle "keep alive" timer. Value is in milliseconds.
333...222999... aaaxxx222555 vvveeerrrsssiiiooonnn [[[111|||222]]]
Display or set the version of the AX.25 protocol to attempt to use on new
connections. The default is 1 (the version that does not use the poll/final
bits).
333...333000... aaaxxx222555 wwwiiinnndddooowww [[[<<<vvvaaalll>>>]]]
- 9 -
Set the number of bytes that can be pending on an AX.25 receive queue beyond
which I frames will be answered with RNR (Receiver Not Ready) responses. This
presently applies only to suspended interactive AX.25 sessions, since incoming
I-frames containing network (IP, NET/ROM) packets are always processed
immediately and are not placed on the receive queue. However, when an AX.25
connection carries both interactive and network packet traffic, an RNR
generated because of backlogged interactive traffic will also stop network
packet traffic from being sent.
333...333111... cccddd [[[<<<dddiiirrrnnnaaammmeee>>>]]]
Change the current working directory, and display the new setting. Without an
argument, cccddd simply displays the current directory without change. The pppwwwddd
command is an alias for cccddd.
333...333222... ccclllooossseee [[[<<<ssseeessssssiiiooonnn ###>>>]]]
Close the specified session; without an argument, close the current session.
On an AX.25 session, this command initiates a disconnect. On a FTP or Telnet
session, this command sends a FIN (i.e., initiates a close) on the session's
TCP connection. This is an alternative to asking the remote server to
initiate a close ("QUIT" to FTP, or the logout command appropriate for the
remote system in the case of Telnet). When either FTP or Telnet sees the
incoming half of a TCP connection close, it automatically responds by closing
the outgoing half of the connection. Close is more graceful than the rrreeessseeettt
command, in that it is less likely to leave the remote TCP in a "half-open"
state.
333...333333... cccooonnnnnneeecccttt <<<iiifffaaaccceee>>> <<<cccaaallllllsssiiigggnnn>>> [[[<<<dddiiigggiiipppeeeaaattteeerrr>>> ......... ]]]
Initiate a "vanilla" AX.25 session to the specified call sign using the
specified interface. Data sent on this session goes out in conventional AX.25
packets with no upper layer protocol. The de-facto presentation standard
format is used, in that each packet holds one line of text, terminated by a
carriage return. A single AX.25 connection may be used for terminal-to-
terminal, IP and NET/ROM traffic, with the three types of data being
automatically separated by their AX.25 Level 3 Protocol IDs.
Up to 7 optional digipeaters may be given; note that the word vvviiiaaa is NOT
needed. If digipeaters are specified, they are automatically added to the AX25
routing table as though the aaaxxx222555 rrrooouuuttteee aaadddddd command had been given before
issuing the connect command.
333...333444... dddeeetttaaaccchhh <<<iiifffaaaccceee>>>
Detach a previously attached interface from the system. All IP routing table
entries referring to this interface are deleted, and forwarding references by
any other interface to this interface are removed.
- 10 -
333...333555... dddiiirrr [[[<<<dddiiirrrnnnaaammmeee>>>]]]
List the contents of the specified directory on the console. If no argument is
given, the current directory is listed. Note that this command works by first
listing the directory into a temporary file, and then creating a mmmooorrreee session
to display it. After this completes, the temporary file is deleted.
333...333666... dddiiissscccooonnnnnneeecccttt [[[<<<ssseeessssssiiiooonnn ###>>>]]]
An alias for the ccclllooossseee command (for the benefit of AX.25 users).
333...333777... dddooommmaaaiiinnn aaaddddddssseeerrrvvveeerrr <<<hhhooossstttiiiddd>>> [[[<<<hhhooossstttiiiddd>>> .........]]]
Add one or more domain name server(s) to the list of name servers.
333...333888... dddooommmaaaiiinnn dddrrrooopppssseeerrrvvveeerrr <<<hhhooossstttiiiddd>>> [[[<<<hhhooossstttiiiddd>>> .........]]]
Remove one or more domain name server(s) from the list of name servers.
333...333999... dddooommmaaaiiinnn llliiissstttssseeerrrvvveeerrrsss
List the currently configured domain name servers, along with statistics on
how many queries and replies have been exchanged with each one, response
times, etc.
333...444000... dddooommmaaaiiinnn sssuuuffffffiiixxx [[[<<<dddooommmaaaiiinnn sssuuuffffffiiixxx>>>]]]
Display or specify the default domain name suffix to be appended to a host
name when it contains no periods. For example, if the suffix is set to
aaammmppprrr...ooorrrggg and the user enters ttteeelllnnneeettt kkkaaa999qqq, the domain resolver will attempt to
find kkkaaa999qqq...aaammmppprrr...ooorrrggg. If the host name being sought contains one or more
periods, however, the default suffix is NOT applied; e.g., ttteeelllnnneeettt fffoooooo...bbbaaarrr
would NOT be turned into fffoooooo...bbbaaarrr...aaammmppprrr...ooorrrggg.
333...444111... dddooommmaaaiiinnn tttrrraaaccceee [[[ooonnn|||oooffffff]]]
Display or set the flag controlling the tracing of domain server requests and
responses. Trace messages will be seen only if a domain name being sought is
not found in the local cache file, ///dddooommmaaaiiinnn...tttxxxttt.
333...444222... eeeccchhhooo [[[aaacccccceeepppttt|||rrreeefffuuussseee]]]
Display or set the flag controlling client Telnet's response to a remote WILL
ECHO offer.
The Telnet presentation protocol specifies that in the absence of a negotiated
agreement to the contrary, neither end echoes data received from the other.
In this mode, a Telnet client session echoes keyboard input locally and
nothing is actually sent until a carriage return is typed. Local line editing
- 11 -
is also performed: backspace deletes the last character typed, while control-U
deletes the entire line.
When communicating from keyboard to keyboard the standard local echo mode is
used, so the setting of this parameter has no effect. However, many
timesharing systems (e.g., UNIX) prefer to do their own echoing of typed
input. (This makes screen editors work right, among other things). Such
systems send a Telnet WILL ECHO offer immediately upon receiving an incoming
Telnet connection request. If eeeccchhhooo aaacccccceeepppttt is in effect, a client Telnet
session will automatically return a DO ECHO response. In this mode, local
echoing and editing is turned off and each key stroke is sent immediately
(subject to the Nagle tinygram algorithm in TCP). While this mode is just
fine across an Ethernet, it is clearly inefficient and painful across slow
paths like packet radio channels. Specifying eeeccchhhooo rrreeefffuuussseee causes an incoming
WILL ECHO offer to be answered with a DONT ECHO; the client Telnet session
remains in the local echo mode. Sessions already in the remote echo mode are
unaffected. (Note: Berkeley Unix has a bug in that it will still echo input
even after the client has refused the WILL ECHO offer. To get around this
problem, enter the sssttttttyyy ---eeeccchhhooo command to the shell once you have logged in.)
333...444333... eeeooolll [[[uuunnniiixxx|||ssstttaaannndddaaarrrddd]]]
Display or set Telnet's end-of-line behavior when in remote echo mode. In
standard mode, each key is sent as-is. In unix mode, carriage returns are
translated to line feeds. This command is not necessary with all UNIX
systems; use it only when you find that a particular system responds to line
feeds but not carriage returns. Only SunOS release 3.2 seems to exhibit this
behavior; later releases are fixed.
333...444444... eeessscccaaapppeee [[[<<<ccchhhaaarrr>>>]]]
Display or set the current command-mode escape character in hex. (This
command is not provided on the IBM-PC; on the PC, the escape char is always
F10.)
333...444555... eeettthhheeerrrssstttaaattt
Display 3-Com Ethernet controller statistics (if configured).
333...444666... eeexxxiiittt
Exit the _n_e_t program and return to MS-DOS (or CP/M).
333...444777... fffiiinnngggeeerrr <<<uuussseeerrr@@@hhhooossstttiiiddd>>> [[[<<<uuussseeerrr@@@hhhooossstttiiiddd>>> .........]]]
Issue a network finger request for user uuussseeerrr at host hhhooossstttiiiddd. This creates a
client session which may be interrupted, resumed, reset, etc, just like a
Telnet client session.
- 12 -
333...444888... ffftttppp <<<hhhooossstttiiiddd>>>
Open an FTP control channel to the specified remote host and enter converse
mode on the new session. Responses from the remote server are displayed
directly on the screen. See the chapter FFFTTTPPP SSSuuubbbcccooommmmmmaaannndddsss for descriptions of
the commands available in an FTP session.
333...444999... hhheeelllppp
Display a brief summary of top-level commands.
333...555000... hhhoooppp ccchhheeeccckkk <<<hhhooossstttiiiddd>>>
Initiate a hhhooopppccchhheeeccckkk session to the specified host. This uses a series of UDP
"probe" packets with increasing IP TTL fields to determine the sequence of
gateways in the path to the specified destination. This function is patterned
after the UNIX tttrrraaaccceeerrrooouuuttteee facility.
ICMP message tracing should be turned off before this command is executed (see
the iiicccmmmppp tttrrraaaccceee command).
333...555111... hhhoooppp mmmaaaxxxttttttlll [[[<<<ttttttlll>>>]]]
Display or set the maximum TTL value to be used in hop check sessions. This
effectively bounds the radius of the search.
333...555222... hhhoooppp mmmaaaxxxwwwaaaiiittt [[[<<<tttiiimmmeee>>>]]]
Display or set the maximum interval, in seconds, that a hopcheck session will
wait for responses at each stage of the trace. The default is 5 seconds.
333...555333... hhhoooppp qqquuueeerrriiieeesss [[[<<<cccooouuunnnttt>>>]]]
Display or set the number of UDP probes that will be sent at each stage of the
trace. The default is 3.
333...555444... hhhoooppp tttrrraaaccceee [[[ooonnn|||oooffffff]]]
Display or set the flag that controls the display of additional information
during a hop check session.
333...555555... hhhooossstttnnnaaammmeee [[[<<<nnnaaammmeee>>>]]]
Display or set the local host's name. By convention this should be the same as
the host's primary domain name. This string is used only in the greeting
messages of the various network servers; note that it does NOT set the
system's IP address.
- 13 -
333...555666... hhhsss
Display statistics about the HS high speed HDLC driver (if configured and
active).
333...555777... iiicccmmmppp eeeccchhhooo [[[ooonnn|||oooffffff]]]
Display or set the flag controlling the asynchronous display of ICMP Echo
Reply packets. This flag must be on for one-shot pings to work (see the pppiiinnnggg
command.)
333...555888... iiicccmmmppp ssstttaaatttuuusss
Display statistics about the Internet Control Message Protocol (ICMP),
including the number of ICMP messages of each type sent or received.
333...555999... iiicccmmmppp tttrrraaaccceee [[[ooonnn|||oooffffff]]]
Display or set the flag controlling the display of ICMP error messages. These
informational messages are generated by Internet routers in response to
routing, protocol or congestion problems. This option should be turned off
before using the hhhooopppccchhheeeccckkk facility because it relies on ICMP Time Exceeded
messages, and the asynchronous display of these messages will be mingled with
hop check command output.
333...666000... iiippp aaaddddddrrreeessssss [[[<<<hhhooossstttiiiddd>>>]]]
Display or set the default local IP address. This command must be given before
an attach command if it is to be used as the default IP address for the
interface.
333...666111... iiippp rrrtttiiimmmeeerrr [[[<<<vvvaaalll>>>]]]
Display or set the IP reassembly timeout. The default is 30 seconds.
333...666222... iiippp ssstttaaatttuuusss
Display Internet Protocol (IP) statistics, such as total packet counts and
error counters of various types.
333...666333... iiippp ttttttlll [[[<<<vvvaaalll>>>]]]
Display or set the default time-to-live value placed in each outgoing IP
datagram. This limits the number of switch hops the datagram will be allowed
to take. The idea is to bound the lifetime of the packet should it become
caught in a routing loop, so make the value somewhat larger than the diameter
of the network.
- 14 -
333...666444... llloooggg [[[ssstttoooppp|||<<<fffiiillleee>>>]]]
Display or set the file name for logging server sessions. If ssstttoooppp is given as
the argument, logging is terminated (the servers themselves are unaffected).
If a file name is given as an argument, server session log entries will be
appended to it.
333...666555... mmmbbboooxxx
Display the status of the mailbox server system (if configured).
333...666666... mmmeeemmmooorrryyy fffrrreeeeee
Display the storage allocator free list. Each entry consists of a starting
address, in hex, and a size, in decimal bytes.
333...666777... mmmeeemmmooorrryyy sssiiizzzeeesss
Display a histogram of storage allocator request sizes. Each histogram bin is
a binary order of magnitude (i.e., a factor of 2).
333...666888... mmmeeemmmooorrryyy ssstttaaatttuuusss
Display a summary of storage allocator statistics. The first line shows the
base address of the heap, its total size, the amount of heap memory available
in bytes and as a percentage of the total heap size, and the amount of memory
left over (i.e., not placed on the heap at startup) and therefore available
for shell subcommands.
The second line shows the total number of calls to allocate and free blocks of
memory, the difference of these two values (i.e., the number of allocated
blocks outstanding), the number of allocation requests that were denied due to
lack of memory, and the number of calls to free() that attempted to free
garbage, e.g., by freeing the same block twice or freeing a garbled pointer.
The third line shows the number of calls to malloc and free that occurred with
interrupts off. In normal situations these values should be zero. The fourth
line shows statistics for the special pool of fixed-size buffers used to
satisfy requests for memory at interrupt time. The variables shown are the
number of buffers currently in the pool, their size, and the number of
requests that failed due to exhaustion of the pool.
333...666999... mmmooodddeee <<<iiifffaaaccceee>>> [[[vvvccc|||dddaaatttaaagggrrraaammm]]]
Control the default transmission mode on the specified AX.25 interface. In
dddaaatttaaagggrrraaammm mode, IP packets are encapsulated in AX.25 UI frames and transmitted
without any other link level mechanisms, such as connections or
acknowledgements.
- 15 -
In vvvccc (virtual circuit) mode, IP packets are encapsulated in AX.25 I frames
and are acknowledged at the link level according to the AX.25 protocol. Link
level connections are opened if necessary.
In both modes, ARP is used to map IP to AX.25 addresses. The defaults can be
overridden with the type-of-service (TOS) bits in the IP header. Turning on
the "reliability" bit causes I frames to be used, while turning on the "low
delay" bit uses UI frames. (The effect of turning on both bits is undefined
and subject to change).
In both modes, IP-level fragmentation is done if the datagram is larger than
the interface MTU. In virtual circuit mode, however, the resulting datagram
(or fragments) is further fragmented at the AX.25 layer if it (or they) are
still larger than the AX.25 pppaaacccllleeennn parameter. In AX.25 fragmentation,
datagrams are broken into several I frames and reassembled at the receiving
end before being passed to IP. This is preferable to IP fragmentation whenever
possible because of decreased overhead (the IP header isn't repeated in each
fragment) and increased robustness (a lost fragment is immediately
retransmitted by the link layer).
333...777000... mmmooorrreee <<<fffiiillleee>>> [[[<<<fffiiillleee>>> .........]]]
Display the specified file(s) a screen at a time. To proceed to the next
screen, press the space bar; to cancel the display, hit the 'q' key. The mmmooorrreee
command creates a session that you can suspend and resume just like any other
session.
333...777111... pppaaarrraaammm <<<iiifffaaaccceee>>> [[[<<<pppaaarrraaammm>>> .........]]]
Invoke a device-specific control routine. On a KISS TNC interface, this sends
control packets to the TNC. Data bytes are treated as decimal. For example,
pppaaarrraaammm aaaxxx000 111 222555555 will set the keyup timer (type field = 1) on the KISS TNC
configured as ax0 to 2.55 seconds (255 x .01 sec). On a SLIP interface, the
param command allows the baud rate to be read (without arguments) or set. The
implementation of this command for the various interface drivers is incomplete
and subject to change.
333...777222... pppiiinnnggg <<<hhhooossstttiiiddd>>> [[[<<<llleeennn>>> [[[<<<iiinnnttteeerrrvvvaaalll>>> [[[<<<iiinnncccffflllaaaggg>>>]]]]]]]]]
Ping (send ICMP Echo Request packets to) the specified host. By default the
data field contains only a small timestamp to aid in determining round trip
time; if the optional llleeennngggttthhh argument is given, the appropriate number of data
bytes (consisting of hex 55) are added to the ping packets.
If iiinnnttteeerrrvvvaaalll is specified, pings will be repeated indefinitely at the specified
interval, in seconds; otherwise a single, "one shot" ping is done. Responses
to one-shot pings appear asynchronously on the command screen, while repeated
pings create a session that may be suspended and resumed. Pinging continues
until the session is manually reset.
The iiinnncccffflllaaaggg option causes a repeated ping to increment the target IP address
for each ping; it is an experimental feature for searching blocks of IP
addresses for active hosts.
- 16 -
333...777333... pppsss
Display all current processes in the system. The fields are as follows:
PPPIIIDDD - Process ID (the address of the process descriptor).
SSSPPP - The current value of the process stack pointer.
ssstttkkksssiiizzzeee - The size of the stack allocated to the process.
mmmaaaxxxssstttkkk - The apparent peak stack utilization of this process. This is done in
a somewhat heuristic fashion, so the numbers should be treated as approximate.
If this number reaches or exceeds the stksize figure, the system is almost
certain to crash; the _n_e_t program should be recompiled to give the process a
larger allocation when it is started.
eeevvveeennnttt - The event this task is waiting for, if it is not runnable.
ffflll - Process status flags. There are three: I (Interrupts enabled), W (Waiting
for event) and S (suspended - not currently used). The I flag is set whenever
a task has executed a pwait() call (wait for event) without first disabling
hardware interrupts. Only tasks that wait for hardware interrupt events will
turn off this flag; this is done to avoid critical sections and missed
interrupts. The W flag indicates that the process is waiting for an event; the
eeevvveeennnttt column will be non-blank. Note that although there may be several
runnable processes at any time (shown in the pppsss listing as those without the W
flag and with blank event fields) only one process is actually running at any
one instant (The Refrigerator Light Effect says that the pppsss command is always
the one running when this display is generated.)
333...777444... pppwwwddd [[[<<<dddiiirrrnnnaaammmeee>>>]]]
An alias for the cccddd command.
333...777555... rrreeecccooorrrddd [[[<<<fffiiillleeennnaaammmeee>>>|||oooffffff]]]
Append to fffiiillleeennnaaammmeee all data received on the current session. Data sent on the
current session is also written into the file except for Telnet sessions in
remote echo mode. The command rrreeecccooorrrddd oooffffff stops recording and closes the file.
333...777666... rrreeemmmooottteee [[[---ppp <<<pppooorrrttt>>>]]] [[[---kkk <<<kkkeeeyyy>>>]]] [[[---aaa <<<kkkiiiccckkkaaaddddddrrr>>>]]] <<<hhhooossstttiiiddd>>> eeexxxiiittt|||rrreeessseeettt|||kkkiiiccckkk
Send a UDP packet to the specified host commanding it to exit the net program,
reset the processor, or force a retransmission on TCP connections. For this
command to be accepted, the remote system must be running the rrreeemmmooottteee server
and the port number specified in the remote command must match the port number
given when the server was started on the remote system. If the port numbers
do not match, or if the remote server is not running on the target system, the
command packet is ignored. Even if the command is accepted there is no
acknowledgement.
- 17 -
The kick command forces a retransmission timeout on all TCP connections that
the remote node may have with the local node. If the -a option is used,
connections to the specified host are kicked instead. No key is required for
the kick subcommand.
The exit and reset subcommands are mainly useful for restarting the net
program on a remote unattended system after the configuration file has been
updated. The remote system should invoke the net program automatically upon
booting, preferably in an infinite loop. For example, under MS-DOS the boot
disk should contain the following in aaauuutttoooeeexxxeeeccc...nnneeettt:
:loop
net
goto :loop
333...777777... ---sss <<<kkkeeeyyy>>>
The exit and reset subcommands of remote require a password. The password is
set on a given system with the ---sss option, and it is specified in a command to
a remote system with the ---kkk option. If no password is set with the ---sss option,
then the exit and reset subcommands are disabled.
Note that rrreeemmmooottteee is an experimental feature in NOS; it is _n_o_t yet supported by
any other TCP/IP implementation.
333...777888... rrreeennnaaammmeee <<<fffiiillleee111>>> <<<fffiiillleee222>>>
Rename fffiiillleee111 to fffiiillleee222.
333...777999... rrreeessseeettt [[[<<<ssseeessssssiiiooonnn>>>]]]
Reset the specified session; if no argument is given, reset the current
session. This command should be used with caution since it does not reliably
inform the remote end that the connection no longer exists. (In TCP a reset
(RST) message will be automatically generated should the remote TCP send
anything after a local reset has been done. In AX.25 the DM message performs
a similar role. Both are used to get rid of a lingering half-open connection
after a remote system has crashed.)
333...888000... rrriiippp aaacccccceeepppttt <<<gggaaattteeewwwaaayyy>>>
Remove the specified gateway from the RIP filter table, allowing future
broadcasts from that gateway to be accepted.
333...888111... rrriiippp aaadddddd <<<hhhooossstttiiiddd>>> <<<iiinnnttteeerrrvvvaaalll>>> [[[<<<ffflllaaagggsss>>>]]]
Add an entry to the RIP broadcast table. The IP routing table will be sent to
hhhooossstttiiiddd every iiinnnttteeerrrvvvaaalll seconds. If ffflllaaagggsss is specified as 1, then "split
horizon" processing will be performed for this destination. That is, any IP
routing table entries pointing to the interface that will be used to send this
update will be removed from the update. If split horizon processing is not
specified, then all routing table entries except those marked "private" will
- 18 -
be sent in each update. (Private entries are never sent in RIP packets).
Triggered updates are always done. That is, any change in the routing table
that causes a previously reachable destination to become unreachable will
trigger an update that advertises the destination with metric 15, defined to
mean "infinity".
Note that for RIP packets to be sent properly to a broadcast address, there
must exist correct IP routing and ARP table entries that will first steer the
broadcast to the correct interface and then place the correct link-level
broadcast address in the link-level destination field. If a standard IP
broadcast address convention is used (e.g., 128.96.0.0 or 128.96.255.255) then
chances are you already have the necessary IP routing table entry, but unusual
subnet or cluster-addressed networks may require special attention. However,
an aaarrrppp aaadddddd command will be required to translate this address to the
appropriate link level broadcast address, e.g.,
arp add 128.96.0.0 ethernet ff:ff:ff:ff:ff:ff
for an Ethernet network, and
arp add 44.255.255.255 ax25 qst-0
for an AX25 packet radio channel.
333...888222... rrriiippp dddrrroooppp <<<dddeeesssttt>>>
Remove an entry from the RIP broadcast table.
333...888333... rrriiippp mmmeeerrrgggeee [[[ooonnn|||oooffffff]]]
This flag controls an experimental feature for consolidating redundant entries
in the IP routing table. When rip merging is enabled, the table is scanned
after processing each RIP update. An entry is considered redundant if the
target(s) it covers would be routed identically by a less "specific" entry
already in the table. That is, the target address(es) specified by the entry
in question must also match the target addresses of the less specific entry
and the two entries must have the same interface and gateway fields. For
example, if the routing table contains
Dest Len Interface Gateway Metric P Timer Use
1.2.3.4 32 ethernet0 128.96.1.2 1 0 0 0
1.2.3 24 ethernet0 128.96.1.2 1 0 0 0
then the first entry would be deleted as redundant since packets sent to
1.2.3.4 will still be routed correctly by the second entry. Note that the
relative metrics of the entries are ignored.
- 19 -
333...888444... rrriiippp rrreeefffuuussseee <<<gggaaattteeewwwaaayyy>>>
Refuse to accept RIP updates from the specified gateway by adding the gateway
to the RIP filter table. It may be later removed with the rrriiippp aaacccccceeepppttt command.
333...888555... rrriiippp rrreeeqqquuueeesssttt <<<gggaaattteeewwwaaayyy>>>
Send a RIP Request packet to the specified gateway, causing it to reply with a
RIP Response packet containing its routing table.
333...888666... rrriiippp ssstttaaatttuuusss
Display RIP status, including a count of the number of packets sent and
received, the number of requests and responses, the number of unknown RIP
packet types, and the number of refused RIP updates from hosts in the filter
table. A list of the addresses and intervals to which periodic RIP updates are
being sent is also shown, along with the contents of the filter table.
333...888777... rrriiippp tttrrraaaccceee [[[000|||111|||222]]]
This variable controls the tracing of incoming and outgoing RIP packets.
Setting it to 0 disables all RIP tracing. A value of 1 causes changes in the
routing table to be displayed, while packets that cause no changes cause no
output. Setting the variable to 2 produces maximum output, including tracing
of RIP packets that cause no change in the routing table.
333...888888... rrrooouuuttteee
With no arguments, rrrooouuuttteee displays the IP routing table.
333...888999... rrrooouuuttteee aaadddddd <<<dddeeesssttt___hhhooossstttiiiddd>>>[[[///bbbiiitttsss]]]|||dddeeefffaaauuulllttt <<<iiifffaaaccceee>>> [[[<<<gggaaattteeewwwaaayyy___hhhooossstttiiiddd>>>
[[[<<<mmmeeetttrrriiiccc>>>]]]]]]
This command adds an entry to the routing table. It requires at least two more
arguments, the host_id of the target destination and the name of the interface
to which its packets should be sent. If the destination is not local, the
gateway's host_id should also be specified. (If the interface is a point-to-
point link, then gggaaattteeewwwaaayyy___hhhooossstttiiiddd may be omitted even if the target is non-local
because this field is only used to determine the gateway's link level address,
if any. If the destination is directly reachable, gggaaattteeewwwaaayyy___hhhooossstttiiiddd is also
unnecessary since the destination address is used to determine the interface
link address).
The optional ///bbbiiitttsss suffix to the destination host id specifies how many
leading bits in the host id are to be considered significant in the routing
comparisons. If not specified, 32 bits (i.e., full significance) is assumed.
With this option, a single routing table entry may refer to many hosts all
sharing a common bit string prefix in their IP addresses. For example, ARPA
Class A, B and C networks would use suffixes of /8, /16 and /24 respectively;
the command
- 20 -
route add 44/8 sl0 44.64.0.2
causes any IP addresses beginning with "44" in the first 8 bits to be routed
to 44.64.0.2; the remaining 24 bits are "don't-cares".
When an IP address to be routed matches more than one entry in the routing
table, the entry with largest bbbiiitttsss parameter (i.e., the "best" match) is used.
This allows individual hosts or blocks of hosts to be exceptions to a more
general rule for a larger block of hosts.
The special destination dddeeefffaaauuulllttt is used to route datagrams to addresses not
matched by any other entries in the routing table; it is equivalent to
specifying a ///bbbiiitttsss suffix of /0 to any destination hostid. Care must be taken
with default entries since two nodes with default entries pointing at each
other will route packets to unknown addresses back and forth in a loop until
their time-to-live (TTL) fields expire. (Routing loops for specific addresses
can also be created, but this is less likely to occur accidentally).
Here are some examples of the route command:
# Route datagrams to IP address 44.0.0.3 to SLIP line #0.
# No gateway is needed because SLIP is point-to point.
route add 44.0.0.3 sl0
# Route all default traffic to the gateway on the local Ethernet
# with IP address 44.0.0.1
route add default ec0 44.0.0.1
# The local Ethernet has an ARPA Class-C address assignment;
# route all IP addresses beginning with 192.4.8 to it
route add 192.4.8/24 ec0
# The station with IP address 44.0.0.10 is on the local AX.25 channel
route add 44.0.0.10 ax0
333...999000... rrrooouuuttteee aaaddddddppprrriiivvvaaattteee <<<dddeeesssttt hhhooossstttiiiddd>>>[[[///bbbiiitttsss]]]|||dddeeefffaaauuulllttt <<<iiifffaaaccceee>>> [[[<<<gggaaattteeewwwaaayyy hhhooossstttiiiddd>>>
[[[<<<mmmeeetttrrriiiccc>>>]]]]]]
This command is identical to rrrooouuuttteee aaadddddd except that it also marks the new entry
as private; it will never be included in outgoing RIP updates.
333...999111... rrrooouuuttteee dddrrroooppp <<<dddeeesssttt hhhooossstttiiiddd>>>
rrrooouuuttteee dddrrroooppp deletes an entry from the table. If a packet arrives for the
deleted address and a default route is in effect, it will be used.
333...999222... ssseeessssssiiiooonnn [[[<<<ssseeessssssiiiooonnn ###>>>]]]
Without arguments, displays the list of current sessions, including session
number, remote TCP or AX.25 address and the address of the TCP or AX.25
control block. An asterisk (*) is shown next to the current session; entering
a blank line at this point puts you in converse mode with that session.
Entering a session number as an argument to the session command will put you
in converse mode with that session. If the Telnet server is enabled, the user
- 21 -
is notified of an incoming request and a session number is automatically
assigned. The user may then select the session normally to converse with the
remote user as though the session had been locally initiated.
333...999333... ssshhheeellllll
Suspends _n_e_t and executes a sub shell ("command processor" under MS-DOS).
When the sub shell exits, _n_e_t resumes (under MS-DOS, enter the eeexxxiiittt command).
Background activity (FTP servers, etc) is also suspended while the subshell
executes. Note that this will fail unless there is sufficient unused memory
for the subshell and whatever command the user tries to run (see the
discussion of ---fff option to nnneeettt...eeexxxeee).
333...999444... sssmmmtttppp gggaaattteeewwwaaayyy [[[<<<hhhooossstttiiiddd>>>]]]
Displays or sets the host to be used as a "smart" mail relay. Any mail sent to
a host not in the host table will instead be sent to the gateway for
forwarding.
333...999555... sssmmmtttppp kkkiiiccckkk
Run through the outgoing mail queue and attempt to deliver any pending mail.
This command is periodically invoked by a timer whenever _n_e_t is running; this
command allows the user to "kick" the mail system manually.
333...999666... sssmmmtttppp mmmaaaxxxcccllliiieeennntttsss [[[<<<vvvaaalll>>>]]]
Displays or sets the maximum number of simultaneous outgoing SMTP sessions
that will be allowed. The default is 10; reduce it if network congestion is a
problem.
333...999777... sssmmmtttppp tttiiimmmeeerrr [[[<<<vvvaaalll>>>]]]
Displays or sets the interval, in seconds, between scans of the outbound mail
queue. For example, sssmmmtttppp tttiiimmmeeerrr 666000000 will cause the system to check for outgoing
mail every 10 minutes and attempt to deliver anything it finds, subject of
course to the sssmmmtttppp mmmaaaxxxcccllliiieeennntttsss limit. Setting a value of zero disables queue
scanning altogether, note that this is the default! This value is recommended
for stand alone IP gateways that never handle mail, since it saves wear and
tear on the floppy disk drive.
333...999888... sssmmmtttppp tttrrraaaccceee [[[<<<vvvaaalll>>>]]]
Displays or sets the trace flag in the SMTP client, allowing you to watch
SMTP's conversations as it delivers mail. Zero (the default) disables
tracing.
- 22 -
333...999999... sssoooccckkkeeettt [[[<<<sssoooccckkkeeettt ###>>>]]]
Without an argument, displays all active sockets, giving their index and type,
the address of the associated protocol control block and the and owner process
ID and name. If the index to an active socket is supplied, the status display
for the appropriate protocol is called. For example, if the socket refers to
a TCP connection, the display will be that given by the tttcccppp ssstttaaatttuuusss command
with the protocol control block address.
333...111000000... ssstttaaarrrttt aaaxxx222555|||dddiiissscccaaarrrddd|||eeeccchhhooo|||ffftttppp|||nnneeetttrrrooommm|||rrreeemmmooottteee|||sssmmmtttppp|||ttteeelllnnneeettt|||ttttttyyyllliiinnnkkk
Start the specified Internet server, allowing remote connection requests.
333...111000111... ssstttoooppp aaaxxx222555|||dddiiissscccaaarrrddd|||eeeccchhhooo|||ffftttppp|||nnneeetttrrrooommm|||rrreeemmmooottteee|||sssmmmtttppp|||ttteeelllnnneeettt|||ttttttyyyllliiinnnkkk
Stop the specified Internet server, rejecting any further remote connect
requests. Existing connections are allowed to complete normally.
333...111000222... tttcccppp iiirrrtttttt [[[<<<vvvaaalll>>>]]]
Display or set the initial round trip time estimate, in milliseconds, to be
used for new TCP connections until they can measure and adapt to the actual
value. The default is 5000 milliseconds (5 seconds). Increasing this when
operating over slow channels will avoid the flurry of retransmissions that
would otherwise occur as the smoothed estimate settles down at the correct
value. Note that this command should be given before servers are started in
order for it to have effect on incoming connections.
TCP also keeps a _c_a_c_h_e of measured round trip times and mean deviations (MDEV)
for current and recent destinations. Whenever a new TCP connection is opened,
the system first looks in this cache. If the destination is found, the cached
IRTT and MDEV values are used. If not, the default IRTT value mentioned above
is used, along with a MDEV of 0. This feature is fully automatic, and it can
improve performance greatly when a series of connections are opened and closed
to a given destination (e.g., a series of FTP file transfers or directory
listings).
333...111000333... tttcccppp kkkiiiccckkk <<<tttcccbbb___aaaddddddrrr>>>
If there is unacknowledged data on the send queue of the specified TCB, this
command forces an immediate retransmission.
333...111000444... tttcccppp mmmssssss [[[<<<sssiiizzzeee>>>]]]
Display or set the TCP Maximum Segment Size in bytes that will be sent on all
outgoing TCP connect request (SYN segments). This tells the remote end the
size of the largest segment (packet) it may send. Changing MSS affects only
future connections; existing connections are unaffected.
- 23 -
333...111000555... tttcccppp rrreeessseeettt <<<tttcccbbb___aaaddddddrrr>>>
Deletes the TCP control block at the specified address.
333...111000666... tttcccppp rrrtttttt <<<tttcccbbb___aaaddddddrrr>>> <<<rrrttttttvvvaaalll>>>
Replaces the automatically computed round trip time in the specified TCB with
the rrrttttttvvvaaalll in milliseconds. This command is useful to speed up recovery from
a series of lost packets since it provides a manual bypass around the normal
backoff retransmission timing mechanisms.
333...111000777... tttcccppp ssstttaaatttuuusss [[[<<<tttcccbbb___aaaddddddrrr>>>]]]
Without arguments, displays several TCP-level statistics, plus a summary of
all existing TCP connections, including TCB address, send and receive queue
sizes, local and remote sockets, and connection state. If tttcccbbb___aaaddddddrrr is
specified, a more detailed dump of the specified TCB is generated, including
send and receive sequence numbers and timer information.
333...111000888... tttcccppp wwwiiinnndddooowww [[[<<<vvvaaalll>>>]]]
Displays or sets the default receive window size in bytes to be used by TCP
when creating new connections. Existing connections are unaffected.
333...111000999... ttteeelllnnneeettt <<<hhhooossstttiiiddd>>>
Creates a Telnet session to the specified host and enters converse mode.
333...111111000... tttiiippp <<<iiifffaaaccceee>>>
Creates a tttiiippp session that connects to the specified interface in "dumb
terminal" mode. The interface must have already been attached with the aaattttttaaaccchhh
command. Any packet traffic (IP datagrams, etc) routed to the interface while
this session exists will be discarded. To close a tttiiippp session, use the rrreeessseeettt
command. It will then revert to normal sssllliiippp,,, nnnrrrsss or kkkiiissssss mode operation.
This feature is primarily useful for manually establishing SLIP connections.
At present, only the built-in "com" ports can be used with this command.
333...111111111... tttrrraaaccceee [[[<<<iiifffaaaccceee>>> [[[<<<ffflllaaagggsss>>> [[[<<<tttrrraaaccceeefffiiillleee>>>]]]]]]]]]
Controls packet tracing by the interface drivers. Specific bits enable tracing
of the various interfaces and the amount of information produced. Tracing is
controlled on a per-interface basis; without arguments, tttrrraaaccceee gives a list of
all defined interfaces and their tracing status. Output can be limited to a
single interface by specifying it, and the control flags can be change by
specifying them as well. The flags are given as a hexadecimal number which is
interpreted as follows:
- 24 -
BTIO
||||--- Enable tracing of output packets if 1, disable if 0
|||---- Enable tracing of input packets if 1, disable if 0
||----- Controls type of tracing:
| 0 - Protocol headers are decoded, but data is not displayed
| 1 - Protocol headers are decoded, and data (but not the
| headers themselves) are displayed as ASCII characters,
| 64 characters/line. Unprintable characters are displayed
| as periods.
| 2 - Protocol headers are decoded, and the entire packet
| (headers AND data) is also displayed in hexadecimal
| and ASCII, 16 characters per line.
|------ Broadcast filter flag. If set, only packets specifically addressed
to this node will be traced; broadcast packets will not be displayed.
If tttrrraaaccceeefffiiillleee is not specified, tracing will be to the console.
333...111111222... uuudddppp ssstttaaatttuuusss
Displays the status of all UDP receive queues.
333...111111333... uuupppllloooaaaddd [[[<<<fffiiillleeennnaaammmeee>>>]]]
Opens fffiiillleeennnaaammmeee and sends it on the current session as though it were typed on
the terminal.
333...111111444... wwwaaatttccchhh
Displays the current software stopwatch values, with min and max readings for
each. This facility allows a programmer to measure the execution time of
critical sections of code with microsecond resolution. This command is
supported only on the IBM PC, and the meaning of each stopwatch value depends
on where the calls have been inserted for test purposes; the distribution copy
of _n_e_t usually has no stopwatch calls.
333...111111555... ???
Same as the hhheeelllppp command.
444... FFFTTTPPP SSSuuubbbcccooommmmmmaaannndddsss
During converse mode with an FTP server, everything typed on the console is
first examined to see if it is a locally-known command. If not, the line is
passed intact to the remote server on the control channel. If it is one of the
following commands, however, it is executed locally. (Note that this generally
involves other commands being sent to the remote server on the control
channel.)
- 25 -
444...111... dddiiirrr [[[<<<fffiiillleee>>>|||<<<dddiiirrreeeccctttooorrryyy>>> [[[<<<lllooocccaaalll fffiiillleee>>>]]]]]]
Without arguments, dddiiirrr requests that a full directory listing of the remote
server's current directory be sent to the terminal. If one argument is given,
this is passed along in the LIST command; this can be a specific file or
subdirectory that is meaningful to the remote file system. If two arguments
are given, the second is taken as the local file into which the directory
listing should be put (instead of being sent to the console). The PORT
command is used before the LIST command is sent.
444...222... gggeeettt <<<rrreeemmmooottteee fffiiillleee>>> [[[<<<lllooocccaaalll fffiiillleee>>>]]]
Asks the remote server to send the file specified in the first argument. The
second argument, if given, will be the name of the file on the local machine;
otherwise it will have the same name as on the remote machine. The PORT and
RETR commands are sent on the control channel.
444...333... hhhaaassshhh
A synonym for the vvveeerrrbbbooossseee 333 command.
444...444... lllsss [[[<<<fffiiillleee>>>|||<<<dddiiirrreeeccctttooorrryyy>>> [[[<<<lllooocccaaalll fffiiillleee>>>]]]]]]
lllsss is identical to the dddiiirrr command except that the "NLST" command is sent to
the server instead of the "LIST" command. This results in an abbreviated
directory listing, i.e., one showing only the file names themselves without
any other information.
444...555... mmmgggeeettt <<<fffiiillleee>>> [[[<<<fffiiillleee>>> .........]]]
Fetch a collection of files from the server. File names may include wild card
characters; they will be interpreted and expanded into a list of files by the
remote system using the NLST command. The files will have the same name on the
local system that they had on the server.
444...666... mmmkkkdddiiirrr <<<rrreeemmmooottteee dddiiirrreeeccctttooorrryyy>>>
Creates a directory on the remote machine.
444...777... mmmpppuuuttt <<<fffiiillleee>>> [[[<<<fffiiillleee>>> .........]]] SSSeeennnddd aaa cccooolllllleeeccctttiiiooonnn ooofff fffiiillleeesss tttooo ttthhheee ssseeerrrvvveeerrr... FFFiiillleee
nnnaaammmeeesss mmmaaayyy iiinnncccllluuudddeee wwwiiilllddd cccaaarrrddd ccchhhaaarrraaacccttteeerrrsss;;; ttthhheeeyyy wwwiiillllll bbbeee eeexxxpppaaannndddeeeddd lllooocccaaallllllyyy iiinnntttooo aaa
llliiisssttt ooofff fffiiillleeesss tttooo bbbeee ssseeennnttt... TTThhheee fffiiillleeesss wwwiiillllll hhhaaavvveee ttthhheee sssaaammmeee nnnaaammmeee ooonnn ttthhheee ssseeerrrvvveeerrr aaasss
ooonnn ttthhheee lllooocccaaalll sssyyysssttteeemmm...
444...888... pppuuuttt <<<lllooocccaaalll fffiiillleee>>> [[[<<<rrreeemmmooottteee fffiiillleee>>>]]]
Asks the remote server to accept data, creating the file named in the first
argument. The second argument, if given, will be the name of the file on the
remote machine; otherwise it will have the same name as on the local machine.
- 26 -
The PORT and STOR commands are sent on the control channel.
444...999... rrrmmmdddiiirrr <<<rrreeemmmooottteee dddiiirrreeeccctttooorrryyy>>>
Deletes a directory on the remote machine.
444...111000... tttyyypppeee [[[aaa|||iii|||lll <<<bbbyyyttteeesssiiizzzeee>>>]]]
Tells both the local client and remote server the type of file that is to be
transferred. The default is 'a', which means ASCII (i.e., a text file). Type
'i' means _i_m_a_g_e, i.e., binary. In ASCII mode, files are sent as varying
length lines of text in ASCII separated by cr/lf sequences; in IMAGE mode,
files are sent exactly as they appear in the file system. ASCII mode should
be used whenever transferring text between dissimilar systems (e.g., UNIX and
MS-DOS) because of their different end-of-line and/or end-of-file conventions.
When exchanging text files between machines of the same type, either mode will
work but IMAGE mode is usually faster. Naturally, when exchanging raw binary
files (executables, compressed archives, etc) IMAGE mode must be used. Type
'l' (logical byte size) is used when exchanging binary files with remote
servers having oddball word sizes (e.g., DECSYSTEM-10s and 20s). Locally it
works exactly like IMAGE, except that it notifies the remote system how large
the byte size is. bbbyyyttteeesssiiizzzeee is typically 8. The type command sets the local
transfer mode and generates the TYPE command on the control channel.
444...111111... vvveeerrrbbbooossseee [[[000|||111|||222|||333]]]
Set or display the level of message output in file transfers. VVVeeerrrbbbooossseee 000 gives
the least output, and vvveeerrrbbbooossseee 333 the most, as follows:
0 - Display error messages only.
1 - Display error messages plus a one-line summary after each transfer
giving the name of the file, its size, and the transfer time and rate.
2 - Display error and summary messages plus the progress messages generated
by the remote FTP server. (This setting is the default.)
3 - Display all messages. In addition, a "hash mark" (#) is displayed for
every 1,000 bytes sent or received.
If a command is sent to the remote server because it is not recognized
locally, the response is always displayed, regardless of the setting of
vvveeerrrbbbooossseee. This is necessary for commands like pppwwwddd (display working directory),
which would otherwise produce no message at all if vvveeerrrbbbooossseee were set to 0 or 1.
555... AAAttttttaaaccchhh CCCooommmmmmaaannndddsss
This section details the attach commands for the various hardware interface
drivers. Not all of these drivers may be configured into every net.exe binary;
a list of the available types may be obtained by entering the command aaattttttaaaccchhh
???.
Some parameters are accepted by several drivers. They are:
- 27 -
555...111... bbbuuufffsssiiizzzeee
For asynchronous devices (e.g., COM ports operating in SLIP or NRS mode) this
parameter specifies the size of the receiver's ring buffer. It should be
large enough to hold incoming data at full line speed for the longest time
that the system may be busy in MS-DOS or the BIOS doing a slow I/O operation
(e.g., to a floppy disk). A kilobyte is usually more than sufficient.
For synchronous devices (e.g., the ssscccccc,,, hhhsss,,, pppccc111000000,,, hhhaaapppnnn and dddrrrsssiii interfaces
operating in HDLC mode), the bufsize parameter specifies the largest packet
that may be received on the interface. This should be set by mutual agreement
among stations sharing the channel. For standard AX.25 with a maximum I-frame
data size of 256 bytes, a value of 325 should provide an adequate safety
margin. On higher speed channels (e.g., 56kb/s) larger values (e.g., 2K bytes)
will provide much better performance and allow full-sized Ethernet packets to
be carried without fragmentation.
555...222... iiioooaaaddddddrrr
The base address of the interface's control registers, in hex.
555...333... vvveeeccctttooorrr
The interface's hardware interrupt (IRQ) vector, in hex.
555...444... iiifffaaaccceee
The name (an arbitrary character string) to be assigned to this interface. It
is used to refer to the interface in iiifffaaaccceee and rrrooouuuttteee commands and in tttrrraaaccceee
output.
555...555... mmmtttuuu
The Maximum Transmission Unit size, in bytes. Datagrams larger than this
limit will be fragmented at the IP layer into smaller pieces. For AX.25 UI
frames, this limits the size of the information field. For AX.25 I frames,
however, the aaaxxx222555 pppaaacccllleeennn parameter is also relevant. If the datagram or
fragment is still larger than pppaaacccllleeennn, it is also fragmented at the AX.25 level
(as opposed to the IP level) before transmission. (See the aaaxxx222555 pppaaacccllleeennn
command for further information).
555...666... aaattttttaaaccchhh 333ccc555000000 <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaarrrpppaaa <<<iiifffaaaccceee>>> <<<qqqllleeennn>>> <<<mmmtttuuu>>> [[[<<<iiippp___aaaddddddrrr>>>]]]
Attach a 3Com 3C501 Ethernet interface. qqqllleeennn is the maximum allowable
transmit queue length. If the iiippp___aaaddddddrrr parameter is not given, the value
associated with a prior iiippp aaaddddddrrreeessssss command will be used.
The use of this driver is not recommended; use the packet driver interface
with the loadable 3C501 packet driver instead.
- 28 -
555...777... aaattttttaaaccchhh aaasssyyy <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> sssllliiippp|||aaaxxx222555|||nnnrrrsss <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>>
<<<ssspppeeeeeeddd>>> [[[<<<ffflllaaagggsss>>>]]]
Attach a "com port" (asynchronous serial port). Standard values on the IBM PC
and clones for iiioooaaaddddddrrr and vvveeeccctttooorrr are 0x3f8 and 4 for COM1, and 0x2f8 and 3 for
COM2. If the port uses a 16550A chip, it will be detected automatically and
the FIFOs enabled.
Three operating modes are available:
555...777...111... sssllliiippp
Encapsulates IP datagrams directly in SLIP frames without a link header. This
is for operation on point-to-point lines and is compatible with 4.2BSD UNIX
SLIP.
555...777...222... aaaxxx222555
Similar to sssllliiippp, except that an AX.25 header and a KISS TNC control header are
added to the front of the datagram before SLIP encoding. Either UI
(connectionless) or I (connection-oriented) AX.25 frames can be used; see the
mmmooodddeee command for details.
555...777...333... nnnrrrsss
Use the NET/ROM asynchronous framing technique for communication with a local
NET/ROM TNC.
555...888... aaattttttaaaccchhh dddrrrsssiii <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>> <<<ccchhh___aaa___ssspppeeeeeeddd>>>
<<<ccchhh___bbb___ssspppeeeeeeddd>>>
Attach a Digital Radio Systems PCPA card. Since there are two channels on the
board, two interfaces are attached. They will be named iiifffaaaccceee with 'a' and 'b'
appended. bbbuuufffsssiiizzzeee is the receiver buffer size in bytes; it must be larger than
the largest frame to be received. ccchhh___aaa___ssspppeeeeeeddd and ccchhh___bbb___ssspppeeeeeeddd are the speeds, in
bits/sec, for the A and B channels, respectively.
555...999... aaattttttaaaccchhh eeeaaagggllleee <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>> <<<ssspppeeeeeeddd>>>
Attach an Eagle Computer 8530 interface card.
555...111000... aaattttttaaaccchhh hhhaaapppnnn <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>> cccsssmmmaaa|||fffuuullllll
Attach a Hamilton Area Packet Network adapter using the Intel 8273 chip. The
cccsssmmmaaa|||fffuuullllll parameter specifies whether the port should operate in carrier sense
multiple access (CSMA) mode or in full duplex.
- 29 -
555...111111... aaattttttaaaccchhh hhhsss <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>> <<<kkkeeeyyyuuuppp___dddeeelllaaayyy>>>
<<<ppp>>>
Attach a DRSI PCPA or Eagle Computer interface card using a special "high
speed" driver. This driver uses busy-wait loops to send and receive each byte
instead of interrupts, making it usable with high speed (56kb/s) modems on
slow systems. This does have the side effect of "freezing" the system whenever
the modem transmitter or receiver is active. This driver can operate only in
CSMA mode, and it is recommended that no other interfaces requiring small
interrupt latencies be attached to the same machine.
The kkkeeeyyyuuuppp___dddeeelllaaayyy parameter specifies the transmitter keyup delay in byte time
intervals. The ppp value specifies the transmitter persistence value in the
range 1-255; the corresponding slot time is fixed at one hardware clock tick,
about 55 ms on the PC.
As with the other 8530 drivers, this driver actually attaches two interfaces,
one for each 8530 channel.
555...111222... aaattttttaaaccchhh pppaaaccckkkeeettt <<<iiinnntttvvveeeccc>>> <<<iiifffaaaccceee>>> <<<tttxxxqqqllleeennn>>> <<<mmmtttuuu>>>
Attach a packet driver conforming to the FTP Software, Inc, Packet Driver
Specification. The driver must have already been installed before the attach
command is given. Packet drivers in the Ethernet, ARCNET, SLIP, KISS/AX25 and
SLFP classes are supported.
iiinnntttvvveeeccc is the software interrupt vector used for communication to the packet
driver, and tttxxxqqqllleeennn is the maximum number of packets that will be allowed on
the transmit queue.
555...111333... aaattttttaaaccchhh pppccc111000000 <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<ssspppeeeeeeddd>>>
Attach a Paccomm PC-100 interface card. Only AX.25 operation is supported.
555...111444... aaattttttaaaccchhh ssscccccc <<<dddeeevvviiiccceeesss>>> iiinnniiittt <<<aaaddddddrrr>>> <<<ssspppaaaccciiinnnggg>>> <<<AAAoooffffff>>> <<<BBBoooffffff>>> <<<DDDaaatttaaaoooffffff>>>
<<<iiinnntttaaaccckkk>>> <<<vvveeeccc>>> [[[ppp]]]<<<cccllloooccckkk>>> [[[hhhdddwwweee]]] [[[pppaaarrraaammm]]]
Initialize a generic SCC (8530) interface board prior to actually attaching
it. The parameters are as follows:
555...111444...111... dddeeevvviiiccceeesss
The number of SCC chips to support.
555...111444...222... aaaddddddrrr
The base address of the first SCC chip (hex).
- 30 -
555...111444...333... ssspppaaaccciiinnnggg
The spacing between the SCC chip base addresses.
555...111444...444... AAAoooffffff
The offset from a chip's base address to its channel A control register.
555...111444...555... BBBoooffffff
The offset from a chip's base address to its channel B control register.
555...111444...666... DDDaaatttaaaoooffffff
The offset from each channel's control register to its data register.
555...111444...777... iiinnntttaaaccckkk
The address of the INTACK/Read Vector port. If none, specify 0 to read from
RR3A/RR2B.
555...111444...888... vvveeeccc
The CPU interrupt vector for all connected SCCs.
555...111444...999... cccllloooccckkk
The clock frequency (PCLK/RTxC) of all SCCs in hertz. Prefix with 'p' for
PCLK, 'r' for RTxC clock (for baudrate gen).
555...111444...111000... hhhdddwwweee
Optional hardware type. The following values are currently supported: 1 -
Eagle card, 2 - PACCOMM PC-100, 4 - PRIMUS-PC card (DG9BL), 8 - DRSI PCPA
card.
555...111444...111111... pppaaarrraaammm
Optional extra parameter. At present, this is used only with the PC-100 and
PRIMUS-PC cards to set the modem mode. The value 0x22 is used with the PC-100
and 0x2 is used with the PRIMUS-PC card.
The aaattttttaaaccchhh ssscccccc ......... iiinnniiittt command must be given before the interfaces are
actually attached with the following command.
- 31 -
555...111555... aaattttttaaaccchhh ssscccccc <<<ccchhhaaannn>>> sssllliiippp|||kkkiiissssss|||nnnrrrsss|||aaaxxx222555 <<<iiifffaaaccceee>>> <<<mmmtttuuu>>> <<<ssspppeeeeeeddd>>> <<<bbbuuufffsssiiizzzeee>>>
[[[cccaaallllll]]]
Attach an initialized SCC port to the system. The parameters are as follows:
555...111555...111... <<<ccchhhaaannn>>>
The SCC channel number to attach, 0 or 1 for the first chip's A or B port, 2
or 3 for the second chip's A or B port, etc.
555...111555...222... sssllliiippp|||kkkiiissssss|||nnnrrrsss|||aaaxxx222555
The operating mode of the interface. sssllliiippp,,, kkkiiissssss and nnnrrrsss all operate the port
hardware in asynchronous mode; sssllliiippp is Internet-standard serial line IP mode,
kkkiiissssss generates SLIP frames containing KISS TNC commands and AX.25 packets and
nnnrrrsss uses NET/ROM local serial link framing conventions to carry NET/ROM
packets. Selecting aaaxxx222555 mode puts the interface into synchronous HDLC mode
that is suitable for direct connection to a half duplex radio modem.
555...111555...333... ssspppeeeeeeddd
The interface speed in bits per second, e.g., 1200. Prefix with 'd' when an
external divider is available to generate the TX clock. When the clock source
is PCLK, this can be a /32 divider between TRxC and RTxC. When the clock is at
RTxC, the TX rate must be supplied at TRxC. This is needed only for full
duplex synchronous operation. When this arg is given as 'ext', the transmit
and receive clocks are external, and the internal baud rate generator (BRG)
and digital phase locked loop (DPLL) are not used.
555...111555...444... AAAttttttaaaccchhh EEExxxaaammmpppllleeesss
Here are some examples of the attach command:
# Attach a 3Com Ethernet controller using the standard 3Com address and
# vector (i.e., as it comes out of the box) to use ARPA-standard
encapsulation.
# The receive queue is limited to 5 packets, and outgoing packets larger
# than 1500 bytes will be fragmented
attach 3c500 0x300 3 arpa ec0 5 1500
# Attach the PC asynch card normally known as "com1" (the first controller)
# to operate in point-to-point slip mode at 9600 baud, calling it "sl0".
# A 1024 byte receiver ring buffer is allocated. Outgoing packets larger
# than 256 bytes are fragmented.
attach asy 0x3f8 4 slip sl0 1024 256 9600
# Attach the secondary PC asynch card ("com2") to operate in AX.25 mode
# with an MTU of 576 bytes at 9600 baud with a KISS TNC, calling it "ax0".
# By default, IP datagrams are sent in UI frames
attach asy 0x2f8 3 ax25 ax0 1024 576 9600
# Attach the packet driver loaded at interrupt 0x7e
- 32 -
# The packet driver is for an Ethernet interface
attach packet 0x7e ethernet 8 1500
666... TTThhheee ///ffftttpppuuussseeerrrsss FFFiiillleee
Since MS-DOS is a single-user operating system (some might say it is a
glorified bootstrap loader), it provides no access control; all files can be
read, written or deleted by the local user. It is usually undesirable to give
such open access to a system to remote network users. Net therefore provides
its own access control mechanisms.
The file ///ffftttpppuuussseeerrrsss controls remote FTP and mailbox access. The FTP default is
_n_o access; if this file does not exist, the FTP server will be unusable. A
remote user must first "log in" to the system with the USER and PASS commands,
giving a valid name and password listed in ///ffftttpppuuussseeerrrsss, before he or she can
transfer files.
Each entry in ///ffftttpppuuussseeerrrsss consists of a single line of the form
username password /path permissions
There must be exactly four fields, and there must be exactly one space between
each field. Comments may be added after the last field. Comment lines begin
with '#' in column one.
uuussseeerrrnnnaaammmeee is the user's login name.
pppaaasssssswwwooorrrddd is the required password. Note that this is in plain text; therefore
it is not a good idea to give general read permission to the root directory.
A password of '*' (a single asterisk) means that any password is acceptable.
///pppaaattthhh is the allowable prefix on accessible files. Before any file or
directory operation, the current directory and the user- specified file name
are joined to form an absolute path name in "canonical" form (i.e., a full
path name starting at the root, with "./" and "../" references, as well as
redundant /'s, recognized and removed). The result MUST begin with the
allowable path prefix; if not, the operation is denied. This field must
always begin with a "/", i.e., at the root directory.
pppeeerrrmmmiiissssssiiiooonnnsss is a decimal number granting permission for read, create and write
operations. If the low order bit (0x1) is set, the user is allowed to read a
file subject to the path name prefix restriction. If the next bit (0x2) is
set, the user is allowed to create a new file if it does not overwrite an
existing file. If the third bit (0x4) is set, the user is allowed to write a
file even if it overwrites an existing file, and in addition he may delete
files. Again, all operations are allowed subject to the path name prefix
restrictions. Permissions may be combined by adding bits, for example, 0x3 (=
0x2 + 0x1) means that the user is given read and create permission, but not
overwrite/delete permission.
For example, suppose ///ffftttpppuuussseeerrrsss on machine pc.ka9q.ampr.org contains the line
friendly test /testdir 7
- 33 -
A session using this account would look like this:
net> ftp pc.ka9q.ampr.org
Resolving pc.ka9q.ampr.org... Trying 128.96.160.1...
FTP session 1 connected to pc.ka9q.ampr.org
220 pc.ka9q.ampr.org FTP version 900418 ready at Mon May 7 16:27:18 1990
Enter user name: friendly
331 Enter PASS command
Password: test [not echoed]
230 Logged in
ftp>
The user now has read, write, overwrite and delete privileges for any file
under /testdir; he may not access any other files.
Here are some more sample entries in ///ffftttpppuuussseeerrrsss:
karn foobar / 7 # User "karn" with password "foobar" may read,
# write, overwrite and delete any file on the
# system.
guest bletch /g/bogus 3 # User "guest" with password "bletch" may read
# any file under /g/bogus and its subdirectories,
# and may create a new file as long as it does
# not overwrite an existing file. He may NOT
# delete any files.
anonymous * /public 1 # User "anonymous" (any password) may read files
# under /public and its subdirectories; he may
# not create, overwrite or delete any files.
This last entry is the standard convention for keeping a repository of public
files; in particular, the username "anonymous" is an established ARPA
convention.
777... TTThhheee ///dddooommmaaaiiinnn...tttxxxttt FFFiiillleee
_N_e_t translates domain names (e.g., "pc.ka9q.ampr.org") to IP addresses (e.g.,
128.96.160.3) through the use of an Internet Domain Name resolver and a local
"cache" file, ///dddooommmaaaiiinnn...tttxxxttt. Whenever the user specifies a domain name,
///dddooommmaaaiiinnn...tttxxxttt is first searched for the desired entry. If it is present, it is
used; if not, and if domain name server(s) have been configured, a query is
sent over the network to the current server. If the server responds, the
answer is appended to the ///dddooommmaaaiiinnn...tttxxxttt file for future use. If the server does
not respond, any additional servers on the list are tried indefinitely in a
round-robin fashion until one responds. If ///dddooommmaaaiiinnn...tttxxxttt does not contain the
desired entry and there are no configured domain name servers, then the
request immediately fails.
If a domain name server is available, and if all references to hostids in your
/aaauuutttoooeeexxxeeeccc...nnneeettt file are in IP address format, then it is possible to start with
a completely empty ///dddooommmaaaiiinnn...tttxxxttt file and have _n_e_t build it for you. However,
you may wish to add your own entries to ///dddooommmaaaiiinnn...tttxxxttt, either because you prefer
to use symbolic domain names in your /aaauuutttoooeeexxxeeeccc...nnneeettt file or you don't have
access to a domain server and you need to create entries for all of the hosts
- 34 -
you may wish to access. Each entry takes one line, and the fields are
separated by tabs. For example:
pc.ka9q.ampr.org. IN A 128.96.160.3
IIINNN is the _c_l_a_s_s of the record. It means _I_n_t_e_r_n_e_t, and it will be found in all
entries. AAA is the _t_y_p_e of the record, and it means that this is an _a_d_d_r_e_s_s
record. Domain name pppccc...kkkaaa999qqq...aaammmppprrr...ooorrrggg therefore has Internet address
128.96.160.3.
Another possible entry is the CCCNNNAAAMMMEEE (Canonical Name) record, e.g.,
ka9q.ampr.org. IN CNAME pc.ka9q.ampr.org.
This says that domain name "ka9q.ampr.org" is actually an alias for the system
with (primary, or _c_a_n_o_n_i_c_a_l) domain name "pc.ka9q.ampr.org." When a domain
name having a CCCNNNAAAMMMEEE record is given to _n_e_t, the system automatically follows
the reference to the canonical name and returns the IP address associated with
that entry.
Entries added automatically by _n_e_t will have an additional field between the
domain name and the class (IIINNN) field, e.g.,
pc.ka9q.ampr.org. 3600 IN A 128.96.160.3
This is the _t_i_m_e-_t_o-_l_i_v_e value, in seconds, associated with the record
received from the server. Clients (such as _n_e_t) caching these records are
supposed to delete them after the time-to-live interval has expired, allowing
for the possibility that the information in the record may become out of date.
Cache expiration is not currently implemented in _n_e_t, but TTLs are recorded in
///dddooommmaaaiiinnn...tttxxxttt in anticipation of this feature. Since ///dddooommmaaaiiinnn...tttxxxttt is a plain text
file, it may be easily edited by the user to delete old records.
Additional types of records, include NS (name server) and SOA (start of
authority) may appear in ///dddooommmaaaiiinnn...tttxxxttt from remote server responses. These are
not currently used by _n_e_t but are retained for future development (such as the
incorporation of a domain name server into _n_e_t itself). Server responses
indicating that a given record does not exist are also recorded in
///dddooommmaaaiiinnn...tttxxxttt. These entries have empty value fields, e.g.,
foobar.ampr.org. 500 IN A
888... SSSeeettttttiiinnnggg BBBuuufffsssiiizzzeee,,, PPPaaacccllleeennn,,, MMMaaaxxxfffrrraaammmeee,,, MMMTTTUUU,,, MMMSSSSSS aaannnddd WWWiiinnndddooowww
Many _n_e_t users are confused by these parameters and do not know how to set
them properly. This section will first review these parameters and then
discuss how to choose values for them. Special emphasis is given to avoiding
interoperability problems that may appear when communicating with non-_n_e_t
implementations of AX.25.
888...111... HHHaaarrrdddwwwaaarrreee PPPaaarrraaammmeeettteeerrrsss
- 35 -
888...111...111... BBBuuufffsssiiizzzeee
This parameter is required by most of _n_e_t's built-in HDLC drivers (e.g., those
for the DRSI PCPA and the Paccomm PC-100). It specifies the size of the buffer
to be allocated for each receiver port. HDLC frames larger than this value
cannot be received.
There is no default bbbuuufffsssiiizzzeee; it must be specified in the aaattttttaaaccchhh command for
the interface.
888...222... AAAXXX222555 PPPaaarrraaammmeeettteeerrrsss
888...222...111... PPPaaacccllleeennn
Paclen limits the size of the data field in an AX.25 I-frame. This value does
_n_o_t include the AX.25 protocol header (source, destination and digipeater
addresses).
Since unconnected-mode (datagram) AX.25 uses UI frames, this parameter has no
effect in unconnected mode.
The default value of pppaaacccllleeennn is 256 bytes.
888...222...222... MMMaaaxxxfffrrraaammmeee
This parameter controls the number of I-frames that _n_e_t may send on an AX.25
connection before it must stop and wait for an acknowledgement. Since the
AX.25/LAPB sequence number field is 3 bits wide, this number cannot be larger
than 7.
Since unconnected-mode (datagram) AX.25 uses UI frames that do not have
sequence numbers, this parameter does _n_o_t apply to unconnected mode.
The default value of mmmaaaxxxfffrrraaammmeee in _n_e_t is 1 frame.
888...333... IIIPPP aaannnddd TTTCCCPPP PPPaaarrraaammmeeettteeerrrsss
888...333...111... MMMTTTUUU
The MTU (Maximum Transmission Unit) is an interface parameter that limits the
size of the largest IP datagram that it may handle. IP datagrams routed to an
interface that are larger than its MTU are each split into two or more
_f_r_a_g_m_e_n_t_s. Each fragment has its own IP header and is handled by the network
as if it were a distinct IP datagram, but when it arrives at the destination
it is held by the IP layer until all of the other fragments belonging to the
original datagram have arrived. Then they are reassembled back into the
complete, original IP datagram. The minimum acceptable interface MTU is 28
bytes: 20 bytes for the IP (fragment) header, plus 8 bytes of data.
- 36 -
There is no default MTU in _n_e_t; it must be explicitly specified for each
interface as part of the aaattttttaaaccchhh command.
888...333...222... MMMSSSSSS
MSS (Maximum Segment Size) is a TCP-level parameter that limits the amount of
data that the _r_e_m_o_t_e TCP will send in a single TCP packet. MSS values are
exchanged in the SYN (connection request) packets that open a TCP connection.
In the _n_e_t implementation of TCP, the MSS actually used by TCP is further
reduced in order to avoid fragmentation at the local IP interface. That is,
the local TCP asks IP for the MTU of the interface that will be used to reach
the destination. It then subtracts 40 from the MTU value to allow for the
overhead of the TCP and IP headers. If the result is less than the MSS
received from the remote TCP, it is used instead.
The default value of MMMSSSSSS is 512 bytes.
888...333...333... WWWiiinnndddooowww
This is a TCP-level parameter that controls how much data the local TCP will
allow the remote TCP to send before it must stop and wait for an
acknowledgement. The actual window value used by TCP when deciding how much
more data to send is referred to as the _e_f_f_e_c_t_i_v_e _w_i_n_d_o_w. This is the smaller
of two values: the window advertised by the remote TCP minus the
unacknowledged data in flight, and the _c_o_n_g_e_s_t_i_o_n _w_i_n_d_o_w, an automatically
computed time-varying estimate of how much data the network can handle.
The default value of WWWiiinnndddooowww is 2048 bytes.
888...444... DDDiiissscccuuussssssiiiooonnn
888...444...111... IIIPPP FFFrrraaagggmmmeeennntttaaatttiiiooonnn vvvsss AAAXXX...222555 SSSeeegggmmmeeennntttaaatttiiiooonnn
IP-level fragmentation often makes it possible to interconnect two dissimilar
networks, but it is best avoided whenever possible. One reason is that when a
single IP fragment is lost, all other fragments belonging to the same datagram
are effectively also lost and the entire datagram must be retransmitted by the
source. Even without loss, fragments require the allocation of temporary
buffer memory at the destination, and it is never easy to decide how long to
wait for missing fragments before giving up and discarding those that have
already arrived. A reassembly timer controls this process. In _n_e_t it is
(re)initialized with the iiippp rrrtttiiimmmeeerrr parameter (default 30 seconds) whenever
progress is made in reassembling a datagram (i.e., a new fragment is
received). It is not necessary that all of the fragments belonging to a
datagram arrive within a single timeout interval, only that the interval
between fragments be less than the timeout.
Most subnetworks that carry IP have MTUs of 576 bytes or more, so
interconnecting them with subnetworks having smaller values can result in
considerable fragmentation. For this reason, IP implementors working with
links or subnets having unusually small packet size limits are encouraged to
use _t_r_a_n_s_p_a_r_e_n_t _f_r_a_g_m_e_n_t_a_t_i_o_n, that is, to devise schemes to break up large IP
datagrams into a sequence of link or subnet frames that are immediately
- 37 -
reassembled on the other end of the link or subnet into the original, whole IP
datagram without the use of IP-level fragmentation. Such a scheme is provided
in AX.25 Version 2.1. It can break a large IP or NET/ROM datagram into a
series of pppaaacccllleeennn-sized AX.25 segments (not to be confused with TCP segments),
one per AX.25 I-frame, for transmission and reassemble them into a single
datagram at the other end of the link before handing it up to the IP or
NET/ROM module. Unfortunately, the segmentation procedure is a new feature in
AX.25 and is not yet widely implemented; in fact, _n_e_t is so far the only known
implementation. This creates some interoperability problems between _n_e_t and
non-_n_e_t nodes, in particular, standard NET/ROM nodes being used to carry IP
datagrams. This problem is discussed further in the section on setting the
MTU.
888...444...222... SSSeeettttttiiinnnggg pppaaacccllleeennn aaannnddd bbbuuufffsssiiizzzeee
The more data you put into an AX.25 I frame, the smaller the AX.25 headers are
in relation to the total frame size. In other words, by increasing pppaaacccllleeennn, you
lower the AX.25 protocol overhead. Also, large data packets reduce the
overhead of keying up a transmitter, and this can be an important factor with
higher speed modems. On the other hand, large frames make bigger targets for
noise and interference. Each link has an optimum value of pppaaacccllleeennn that is best
discovered by experiment.
Another thing to remember when setting pppaaacccllleeennn is that the AX.25 version 2.0
specification limits it to 256 bytes. Although _n_e_t can handle much larger
values, some other AX.25 implementations (including digipeaters) cannot and
this may cause interoperability problems. Even _n_e_t may have trouble with
certain KISS TNCs because of fixed-size buffers. The original KISS TNC code
for the TNC-2 by K3MC can handle frames limited in size only by the RAM in the
TNC, but some other KISS TNCs cannot.
_N_e_t's built-in HDLC drivers (SCC, PC-100, DRSI, etc) allocate receive buffers
according to the maximum expected frame size, so it is important that these
devices be configured with the correct bbbuuufffsssiiizzzeee. To do this, you must know the
size of the largest possible frame that can be received. The pppaaacccllleeennn parameter
controls only the size of the data field in an I-frame and not the total size
of the frame as it appears on the air. The AX.25 spec allows up to 8
digipeaters, so the largest possible frame is (pppaaacccllleeennn + 72) bytes. So you
should make bbbuuufffsssiiizzzeee at least this large.
Another important consideration is that the more recent versions of NOS
improve interrupt response by maintaining a special pool of buffers for use by
the receive routines. These buffers are currently fixed in size to 2048 bytes
and this can be changed only by editing config.h and recompiling NOS. This
limits bbbuuufffsssiiizzzeee; in fact, attempting to set a larger value may cause the driver
not to work at all. This situation can be detected by running the mmmeeemmmooorrryyy
ssstttaaatttuuusss command and looking for a non-zero count of IIIbbbuuuffffffaaaiiilll events, although
these events can also occur occasionally during normal operation.
One of the drawbacks of AX.25 that there is no way for one station to tell
another how large a packet it is willing to accept. This requires the
stations sharing a channel to agree beforehand on a maximum packet size. TCP
is different, as we shall see.
- 38 -
888...444...333... SSSeeettttttiiinnnggg MMMaaaxxxfffrrraaammmeee
For best performance on a half-duplex radio channel, mmmaaaxxxfffrrraaammmeee should always be
set to 1. The reasons are explained in the paper _L_i_n_k _L_e_v_e_l _P_r_o_t_o_c_o_l_s
_R_e_v_i_s_i_t_e_d by Brian Lloyd and Phil Karn, which appeared in the proceedings of
the ARRL 5th Computer Networking Conference in 1986.
888...444...444... SSSeeettttttiiinnnggg MMMTTTUUU
TCP/IP header overhead considerations similar to those of the AX.25 layer when
setting pppaaacccllleeennn apply when choosing an MTU. However, certain subnetwork types
supported by _n_e_t have well-established MTUs, and these should always be used
unless you know what you're doing: 1500 bytes for Ethernet, and 508 bytes for
ARCNET. Other subnet types, including SLIP and AX.25, are not as well
standardized. SLIP has no official MTU, but the most common implementation
(for BSD UNIX) uses an MTU of 1006 bytes. Although _n_e_t has no hard wired
limit on the size of a received SLIP frame, this is not true for other
systems. Interoperability problems may therefore result if larger MTUs are
used in _n_e_t.
Choosing an MTU for an AX.25 interface is more complex. When the interface
operates in datagram (UI-frame) mode, the pppaaacccllleeennn parameter does not apply. The
MTU effectively becomes the pppaaacccllleeennn of the link. However, as mentioned
earlier, large packets sent on AX.25 _c_o_n_n_e_c_t_i_o_n_s are automatically segmented
into I-frames no larger than pppaaacccllleeennn bytes. Unfortunately, as also mentioned
earlier, _n_e_t is so far the only known implementation of the new AX.25
segmentation procedure. This is fine as long as all of the NET/ROM nodes along
a path are running _n_e_t, but since the main reason _n_e_t supports NET/ROM is to
allow use of existing NET/ROM networks, this is unlikely.
So it is usually important to avoid AX.25 segmentation when running IP over
NET/ROM. The way to do this is to make sure that packets larger than pppaaacccllleeennn
are never handed to AX.25. A NET/ROM transport header is 5 bytes long and a
NET/ROM network header takes 15 bytes, so 20 bytes must be added to the size
of an IP datagram when figuring the size of the AX.25 I-frame data field. If
pppaaacccllleeennn is 256, this leaves 236 bytes for the IP datagram. This is the default
MTU of the nnneeetttrrrooommm pseudo-interface, so as long as pppaaacccllleeennn is at least 256
bytes, AX.25 segmentation can't happen. But if smaller values of pppaaacccllleeennn are
used, the nnneeetttrrrooommm MTU must also be reduced with the iiifffcccooonnnfffiiiggg command.
On the other hand, if you're running IP directly on top of AX.25, chances are
all of the nodes are running _n_e_t and support AX.25 segmentation. In this case
there is no reason not to use a larger MTU and let AX.25 segmentation do its
thing. If you choose an MTU on the order of 1000-1500 bytes, you can largely
avoid IP-level fragmentation and reduce TCP/IP-level header overhead on file
transfers to a very low level. And you are still free to pick whatever pppaaacccllleeennn
value is appropriate for the link.
888...444...555... SSSeeettttttiiinnnggg MMMSSSSSS
The setting of this TCP-level parameter is somewhat less critical than the IP
and AX.25 level parameters already discussed, mainly because it is
automatically lowered according to the MTU of the local interface when a
connection is created. Although this is, strictly speaking, a protocol
- 39 -
layering violation (TCP is not supposed to have any knowledge of the workings
of lower layers) this technique does work well in practice. However, it can
be fooled; for example, if a routing change occurs after the connection has
been opened and the new local interface has a smaller MTU than the previous
one, IP fragmentation may occur in the local system.
The only drawback to setting a large MSS is that it might cause avoidable
fragmentation at some other point within the network path if it includes a
"bottleneck" subnet with an MTU smaller than that of the local interface.
(Unfortunately, there is presently no way to know when this is the case.
There is ongoing work within the Internet Engineering Task Force on a "MTU
Discovery" procedure to determine the largest datagram that may be sent over a
given path without fragmentation, but it is not yet complete.) Also, since
the MSS you specify is sent to the remote system, and not all other TCPs do
the MSS-lowering procedure yet, this might cause the remote system to generate
IP fragments unnecessarily.
On the other hand, a too-small MSS can result in a considerable performance
loss, especially when operating over fast LANs and networks that can handle
larger packets. So the best value for MSS is probably 40 less than the largest
MTU on your system, with the 40-byte margin allowing for the TCP and IP
headers. For example, if you have a SLIP interface with a 1006 byte MTU and an
Ethernet interface with a 1500 byte MTU, set MSS to 1460 bytes. This allows
you to receive maximum-sized Ethernet packets, assuming the path to your
system does not have any bottleneck subnets with smaller MTUs.
888...444...666... SSSeeettttttiiinnnggg WWWiiinnndddooowww
A sliding window protocol like TCP cannot transfer more than one window's
worth of data per round trip time interval. So this TCP-level parameter
controls the ability of the remote TCP to keep a long "pipe" full. That is,
when operating over a path with many hops, offering a large TCP window will
help keep all those hops busy when you're receiving data. On the other hand,
offering too large a window can congest the network if it cannot buffer all
that data. Fortunately, new algorithms for dynamic controlling the effective
TCP flow control window have been developed over the past few years and are
now widely deployed. _N_e_t includes them, and you can watch them in action with
the tttcccppp ssstttaaatttuuusss <<<tttcccbbb>>> or sssoooccckkkeeettt <<<sssoooccckkknnnooo>>> commands. Look at the cccwwwiiinnnddd
(congestion window) value.
In most cases it is safe to set the TCP window to a small integer multiple of
the MSS, e.g., 4x, or larger if necessary to fully utilize a high
bandwidth*delay product path. One thing to keep in mind, however, is that
advertising a certain TCP window value declares that the system has that much
buffer space available for incoming data. _N_e_t does not actually preallocate
this space; it keeps it in a common pool and may well "overbook" it,
exploiting the fact that many TCP connections are idle for long periods and
gambling that most applications will read incoming data from an active
connection as soon as it arrives, thereby quickly freeing the buffer memory.
However, it is possible to run _n_e_t out of memory if excessive TCP window sizes
are advertised and either the applications go to sleep indefinitely (e.g.,
suspended Telnet sessions) or a lot of out-of-sequence data arrives. It is
wise to keep an eye on the amount of available memory and to decrease the TCP
window size (or limit the number of simultaneous connections) if it gets too
low.
- 40 -
Depending on the channel access method and link level protocol, the use of a
window setting that exceeds the MSS may cause an increase in channel
collisions. In particular, collisions between data packets and returning
acknowledgements during a bulk file transfer may become common. Although this
is, strictly speaking, not TCP's fault, it is possible to work around the
problem at the TCP level by decreasing the window so that the protocol
operates in stop-and-wait mode. This is done by making the window value equal
to the MSS.
888...555... SSSuuummmmmmaaarrryyy
In most cases, the default values provided by _n_e_t for each of these parameters
will work correctly and give reasonable performance. Only in special
circumstances such as operation over a very poor link or experimentation with
high speed modems should it be necessary to change them.